Rebuilding from source

Contents|Previous
Rebuilding from source

The following documentation explains how to rebuild the GNUPro tools using the binary files from source installation, and how to configure your system before you rebuild the binaries from source code for a specified toolchain.

IMPORTANT:
In the following documentation, `gnupro-99r1` is the input (as the current version of GNUPro Toolkit) to substitute for the variable, `release_name`.

You'll need to provide the following specifications when rebuilding:

- Where to install the binaries; see Configuring the location of the tools.
- Which target system will run your final target machine's code; see Configuring when using an embedded target.
- Preparing sources so that you get what you expect; see Preparing to rebuild source code files
Then see Building and installing binaries.

For any problems, see Accessing Cygnus Web Support to report problems, and, also, see Troubleshooting the rebuilding process, configure problem reporting, and build problem reporting.
Finally, see Patching for details on correcting the problems.

### Configuring the location of the tools

The `--prefix=` option specifies the base installation path for the entire toolkit. In the following descriptions, the name of your current GNUPro software release is written in italics as `release_name`.

- To install GNUPro Toolkit in `/yourdirectory/cygnus/release_name`, use the following example's directive.

`--prefix=/yourdirectory/cygnus/release_name`

- To install GNUPro Toolkit in `/usr/cygnus/release_name`, use the following example's directive.

`--prefix=/usr/cygnus/release_name`

GNUPro binaries are typically located in `/usr/cygnus/release_name`.
To rebuild GNUPro Toolkit and install it in the same location as the Cygnus binaries, use the following input.

`--prefix=/usr/cygnus/release_name`
`--exec-prefix=/usr/cygnus/release_name/H-host`

`--exec-prefix=`is useful for sites with multiple host architectures in a networked, shared file system. See also Multiple host builds. `host` stands for the canonical name describing the host. For instance, for a SPARC Solaris 2.5 system, "`sparc-sun-solaris2.5`" is the canonical name. For a complete listing of the current hosts and their canonical naming conventions, see Naming hosts and targets.

Warning!
The values of both `--prefix=` and `--exec-prefix=` must be absolute pathnames.

### Configuring when using an embedded target

If you are targeting an embedded system, remember at configure time to specify the `--target=` option. The `--target=` option value is printed on the CD-ROM you receive from Cygnus. It will be a hyphenated string indicating target and output format.
For example, `m68k-elf` or `powerpc-eabi` would be two such target names with their appropriate output file formats for, respectively, the Motorola 68000 family of processors and the PowerPC series of processors.

Note:
To build a native toolkit, do not use the `--target=` option. For instance, programs such as the GNU debugger or the GNU compiler will run on an IRIX 5 system and output programs which also run on an IRIX 5 system. In this situation, the `--target=` option is unnecessary. `configure` will default to native configuration when using `--target`.

Warning!
For VxWorks users building a cross toolkit with the target board running the VxWorks from Wind River Systems, remember to add the `--with-includes=` command option to `configure`, designating the value for header files with your VxWorks distribution.
If the VxWorks tools are in `/yourdirectory/wrs/vxworks-5.2/`, then the header files are probably in the `/yourdirectory/wrs/vxworks-5.2/h` directory.
Add the `--with-includes=/yourdirectory/wrs/vxworks-5.2/h` command option when you use the `configure` input. If you do not add this command line option, your toolchain will not work.

### Preparing to rebuild source code files

The first and most important step in preparing source code to run on your system is to configure it so that, when built, the program exhibits the behavior you expect. The configuration process automatically prepares a Makefile containing default and/or customized information for your site and for your system. If you are building for more than one platform, you must configure, compile, and install on each platform.
Source code is normally in `/usr/cygnus/release_name/src` . Good practice is to configure and build the source in another directory; any other clean directory will do. In the following examples of commands, the path is from the `/yourdirectory/cygnus` directory.
The build process may take hundreds of megabytes of disk space.

Warning!
Never build your toolkit in the source directory.
Rebuilding in your source directory will overwrite Makefiles, prohibiting reconfiguration.

The default action for `configure` is to configure a native toolchain for the host on which you run the script. At minimum, specify `--prefix=` to point to your installation directory. For cross-compiler toolchains, you must also specify `--target`. The following examples use a directory for the build location with the following name.

`/usr/cygnus/release_name/build`

To configure a native toolchain, use the following example.

`mkdir /usr/cygnus/release_name /build`
`cd /usr/cygnus/release_name /build`
`/usr/cygnus/release_name/src/configure`
`--prefix=/yourdirectory/cygnus/release_name`

To configure a toolchain in `/opt/cygnus` for a Motorola 68000 target with ELF output file format, use the following example's steps.

`mkdir /usr/cygnus/release_name/build`
`cd /usr/cygnus/release_name/build`
`/usr/cygnus/release_name/src/configure --target=m68k-elf\`
`--prefix=/yourdirectory/cygnus/release_name`

Note:
`--target=` is only for cross development.`--target=` is unneccessary for native configuration. `configure` will default to native configuration when using `--target`.

Expect `configure` to take approximately 15-45 minutes to run, depending on the load of your build system, the toolchain being configured and the sources used.

### Building and installing binaries

After you configure the toolchain, build and install the binary programs.
For single host-target builds, see Single host-target builds for details.
For multiple host builds, see Multiple host builds for details.
Some vendor-supplied make programs do not build the toolkit correctly, so for simplicity, use GNU `make` to rebuild from source. A precompiled copy of GNU `make` is in GNUPro Toolkit.
If you are not familiar with `make`, see in Using `make` in GNUPro Utilities.

#### Single host-target builds

In the following example, a copy of GNU `make` is in `/usr/local/bin` and is called `make`.

1. Move to the build directory, using instructions like the following input.

`cd /usr/cygnus/release_name/build`

2. Then, use the following instruction to run `make` .

`/usr/local/bin/make all`

This takes a while to complete.

3. When `make all` finishes, install the tools with the following input.

`/usr/local/bin/make install`

When you have verified that your toolchain is functioning properly, you may remove the `build` directory to conserve disk space.

#### Multiple host builds

GNUPro Toolkit is designed for a kind of multiple-host environment. Set up the tools this way by adding a --`exec-prefix=` command line option to `configure` when configuring the toolkit. This then allows having a directory named `/usr/cygnus/release_name`, with multiple hosts and target versions in one place.
The host-specific files will then be in `/usr/cygnus/release_name/H-hostspec`. `hostspec` stands for the canonical name describing the host. For instance, for a SPARC Solaris 2.5 system, "`sparc-sun-solaris2.5`" is the canonical name.
Consider, then, using the GNUPro tools. A compiler, for whatever target it addresses, is a host-specific program, meaning that it only runs on one host system. A help file is host-independent and it is independent of its host system.
So, imagine you have, for instance, Motorola 68000 systems and IBM PowerPC running AIX 4.2 on one network. There is support for native compilers on both systems, and you want a single `/usr/cygnus` directory that can be NFS-mounted on all of your machines. You should then use the following process.

1. Place all the programs that run on Motorola 60000 systems using the ELF object file format in the following location.

`/usr/cygnus/release_name/H- m68k-elf`

2. Then, place all the programs that run on PowerPC systems in the following location.

`/usr/cygnus/release_name/H-powerpc-ibm-aix4.2`

This shares the `man` pages, text configuration files, and other files for GNUPro Toolkit.

### Troubleshooting the rebuilding process

The following documentation discusses warnings or error messages that may display during your build process. Each message has a troubleshooting approach accompanying it for resolution of the problem that you're addressing.
If the cause of the problem is still not clear, send in a problem report. For a complete description of the automatic problem reporting system, see How to report problems and, to report a problem, see Accessing Cygnus Web Support.

#### Error messages and warnings

The following warnings or error messages may display.

> `Make: Fatal error: Don't know how to make target foo.c`

> The most likely problem is that you are not using GNU `make`.

Use the `--version` option for telling which version you are running; if you have this error message, run the command, `make --version`.

If you are not using GNU `make`, the `make` program will not recognize the `--version` option.

> `Incorrect compiler used`

When `configure` runs, it looks for an appropriate compiler, first `gcc`, then `cc`. If neither of these is correct, specify the name of the compiler at configuration time. We recommend that you always build with the GNU compiler, using the `gcc` command. Specify the compiler by setting the `$CC` environment variable before running `configure`. The following example is the input for the appropriate path for the GCC compiler.

`/usr/cygnus/gnupro-99r1/bin/gcc`

- With a C shell, use a command similar to the following example's input (where `/yourdirectory/vendor/bin/` is the path of the compiler, `not-your-usual-`cc).

`set CC /yourdirectory/vendor/bin/not-your-usual-cc`
`configure`
`...`
`make`

- With a Bourne shell (`/bin/sh` ) or a Korn shell, use the following example's input (where `/yourdirectory/vendor/bin/` is the path of the compiler, `not-your-usual-cc`).

`CC= /yourdirectory/vendor/bin/not-your-usual-cc`
`export CC`
`configure`
`...`
`make`

If you still experience configuration problems, first try to rerun `configure` by adding the command line option, `--verbose`. It's best to redirect the output to a log file while running this process.

- With a C shell, use a command similar to the following example's input.

`configure --verbose ... >& configure.out`

- With a Bourne shell, use the following example's input.

`configure --verbose ... >configure.out 2>&1`

Some seemingly unrelated problems arise after applying patches or making other changes. For instance, sometimes file dependencies get confused. With any trouble you have building, an easy step to take is to remove your build directory completely and then rebuild in an empty build directory, using input like the following example (where `/release_name` is the version name of the GNUPro Toolkit which you are using).

`rm -rf /usr/cygnus/release_name/build`
`mkdir /usr/cygnus/release_name/build`

For more information on installing GNUPro Toolkit, see Installing GNUPro Toolkit.
If it's not obvious which part of the toolkit is failing, check the last line in the log that begins "`Configuring...`" such as with the debugging tool, GDB, where you'd see the status message, "`Configuring gdb...`" before `configure` stops.
`configure` also creates a `config.log` file in each sub-directory in which it runs tests. Check the end of the `config.log` that failed for specific information about what went wrong. The last page (25-30 lines) of this file should be plenty, but if in doubt, send the entire file. For help, contact Cygnus. For information on contacting Cygnus technical support, see How to contact Cygnus.

### `configure` problem reporting

If the cause of the problem is still not clear, send in a problem report.
For a complete description of the automatic problem reporting system, see How to report problems.
If your configuration problems are still confusing, send in the `configure` file's top-level `config.status` file. This file shows which command line options were used to configure the toolkit.
`config.status` (assuming the example pathnames we've used) should be in the `/usr/cygnus/release_name/build/config.status` directory.
The `--verbose` option for `configure` produces the entire output from the last directory. For instance, if `configure` fails in the `gas` directory, send in everything after the line which reads "`Configuring gas...`" and, if in doubt, send us a copy of all the output generated by `configure --verbose`; so that Cygnus technical support staff can more easily determine the problem and quickly resolve it.

### `build` problem reporting

If your build problems are still confusing, report the `build` problem (see Accessing Cygnus Web Support).

IMPORTANT:
Use "`build`" for your category when creating a new problem's report.

First, verify that you're using GNU `make`, using the process outlined in the examples with the "`Make: Fatal error: Don't know how to make target foo.c` " error (see Error messages and warnings).
Cygnus Support staff representatives need the following information when you report the problem.

- Send the top-level `config.status` file. This file will indicate which command line options were used to configure the toolkit. Using the example pathnames that we've used, find the file at `/usr/cygnus/release_name/build/config.status`.
- Send the output of the `make` command that is failing. Only the output from the last directory is probably useful, just as with a `configure` problem report. If in doubt, send the entire output from `make` and Cygnus technical support staff will determine the problem and resolve it.

### Patching

After submitting a problem's report to Cygnus, your solution is known as a patch.
To apply a patch to your source code, you will need to move to the source directory (using the shell commandline declarations,`cd` into the `src` directory). The full default pathname for the source directory is `/usr/cygnus/release_name/src.` Save the patch as a file, such as `/tmp/patch`, and run the `patch` program.

`patch -p < /tmp/patch`

You do not need to edit out all the non-patch text from the file, `/tmp/patch` . The `patch` program will recognize where the real patch begins.

IMPORTANT:
Do not cut-and-paste the patch with a windowing system like X-Windows; tab characters are important and they are usually not preserved correctly when using cut-and-pasting methods.

See also Invoking `patch` and Options to `patch` in Using `diff` & `patch` in GNUPro Utilities. If the patch is rejected, there will be a filename ending in '`.rej`' in the source directory; for instance, if the patch was for a file in the '`src/gcc/reload.c` ' path, and the patch was rejected, '`src/gcc/reload.c.rej`' is the rejection found there. Although it will take a while to run, you can search all files for a rejected patch with a command like the following example.

`find . -name '*.rej' -print`

Top|Contents|Previous